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CROSS-REFERENCE TO RELATED APPLICATION(S) 

[0001] The present application claims priority from U.S. provisional patent application 
no. 60/462,852, filed April 14, 2003, entitled "EXTENSIBLE SENSOR MONITORING, 
ALERT PROCESSING AND NOTIFICATION SYSTEM AND METHOD," naming 
inventor Michael Primm and Richard Jefts, Jr., which application is incorporated by 
reference herein in its entirety. 

FIELD OF DISCLOSURE 

[0002] This disclosure relates generally to a method and system for implementing an 
extensible sensor monitoring, alert processing and notification system. 

BACKGROUND 

[0003] Embedded monitoring systems, due to their memory and processing limitations, 
typically implement monitoring and thresholding applications that provide very specific 
and limited functionality. On typical systems, error monitoring for specific sensors or 
sensor types is often limited to simple range thresholding (based on comparing the sensor 
value to a prescribed maximum and/or minimum value). Typically, the thresholding 
capabilities for any given sensor are limited in several ways. Generally, only one 
threshold logic (min-max, above-for-time, etc) is available for a specific sensor or sensor 
type. Often, only one single instance of a threshold type can be used for a given sensor, 
such as only one range is able to be defined. Most typical systems lack a means by which 
severity can be assigned to an alert reported when a threshold is violated. This can 
restrict the ability to control the level of response to the problem. Most typical systems 
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lack a means by which the status of more than one threshold logic can be combined 
together to produce more sophisticated logic, such as reporting a problem when both a 
temperature value is exceeded and a humidity value is out of range. 

[0004] Another set of limitations typically associated with embedded monitoring 
appliances is limited alert processing functionality. Typical alert handling systems, 
particularly in embedded monitoring devices, include limitations such as: support for 
only a fixed set of alert response types, such as sending e-mail, SNMP traps, or 
alphanumeric pages; limited control over the invocation of responses based on time, the 
type of alert, the alert severity, or the age of the alert condition; and little or no support 
for capturing and saving data during alert processing to provide for delayed access or 
delivery of alert information. 

[0005] Accordingly, an improved method and system for sensor monitoring, alert 
processing, and notification would be desirable. 

SUMMARY 

[0006] In a particular embodiment, the disclosure is directed to a system including a data 
management system configured to receive sensor data associated with a sensor, a 
monitoring system coupled to the data management system, and an alert handling system 
responsive to the data management system and configured to access an alert profile 
associated with an error object provided by the monitoring system. The monitoring 
system is configured to provide the error object in response to a monitoring algorithm 
associated with the sensor data. 

[0007] In a further embodiment, the disclosure is directed to a monitoring appliance 
including a processor and a memory responsive to the processor. The memory includes 
computer implemented instructions operable by the processor to implement a data 
management system configured to receive sensor data associated with a sensor, computer 
implemented instructions operable by the processor to implement a monitoring system 
coupled to the data management system, and computer implemented instructions 
operable by the processor to implement an alert handling system responsive to the data 
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management system and configured to access an alert profile associated with an error 
object provided by the monitoring system. The monitoring system is configured to 
provide an error object in response to a monitoring algorithm associated with the sensor 
data. 

[0008] In another embodiment, the disclosure is directed to an interface including an alert 
action interface configured to receive data associated with an alert action, an alert profile 
interface configured to associate an alert profile sequence with an alert profile, and a 
sensor configuration interface configured to associate condition logic with sensor data. 
The alert profile sequence is associated with the alert action. The alert profile is 
responsive to an error object. The condition logic configured to produce the error object 
in response to the sensor data. 

[0009] In a further embodiment, the disclosure is directed to a method of alert processing 
including generating an error object in response to a change in sensor data, initiating an 
alert profile sequence in response to the error object and performing an alert action in 
response to the alert profile sequence. 

BRIEF DESCRIPTION OF THE DRAWINGS 
[0010] FIG, 1 is a block diagram that depicts an exemplary embodiment of the system. 

[0011] FIGs. 2 through 15 are screen shots that illustrate exemplary interfaces to the 
system. 

[0012] FIGs. 16 and 17 are flow charts that illustrate exemplary methods of using the 
system. 

[0013] FIG. 18 is a block diagram that depicts an exemplary embodiment of a 
monitoring appliance. 

[0014] The use of the same reference symbols in different drawings indicates similar or 
identical items. 
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DETAILED DESCRIPTION 

[0015] In a particular embodiment, the disclosure describes a modular and extensible set 
of applications that implement a versatile and robust monitoring and alert processing 
system. The system includes logic for defining the processing and handling of sensor 
data, logic for implementing rules to identify undesirable conditions (alerts) based on the 
measured values of those sensors, and logic for handling notifications to report alerts. In 
addition, the system may provide for an extensible, data-driven mechanism to 
automatically generate and present user interfaces for additional monitoring and alerting 
components. 

[0016] The term 'monitoring appliance', as used in this disclosure, generally refers to a 
low-cost computing device built to perform a well-defined set of functions centered on 
the acquisition and processing of analog and digital sensor readings. Unlike personal 
computers (PCs) and other large scale computing devices, monitoring appliances 
typically have limited storage and limited computing power. Storage generally includes 
random access memory (RAM) and Flash memory. In general, mechanisms for 
collecting and producing the sensor readings in such an appliance involve significant 
interrupt mode and kernel mode processing unlike monitoring applications on PC 
devices. Applications on PC devices typically do the bulk of data collection and 
processing in "user mode," where full operating system functionality is available. In 
particular examples, the monitoring appliance may include applications for alarming and 
data communication through networks using standards, such as hypertext transfer 
protocol (HTTP), file transfer protocol (FTP), simple mail transfer protocol (SMTP), 
short message service (SMS), and simple network management protocol (SNMP). 
However, the system and method may be implemented in a PC or server system. 

[0017] An exemplary device, such as the exemplary systems described below in relation 
to FIG. 1 8, includes interfaces to sensors and cameras for monitoring a space or 
environment about equipment. Cameras and microphones may also be used to monitor 
visual and audible indicators provided by the equipment. The device may include a 
connection to the equipment to monitor equipment operability, such as through SNMP. 
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The device may journal sensor data. The data may be monitored by a monitoring 
subsystem. In the event of error conditions, an alert handling system may generate 
notifications and communicate with remote systems, such as telephonic or remote 
network systems. 

[0018] Referring to FIG. 1, a particular embodiment of a system is implemented as a 
logical, event-driven pipeline. The system 100 includes sensors 102, data management 
system 104, monitoring policy subsystem 106, add-on policy class definitions 108, alert 
handling subsystem 110, add-on alert action handler definitions 118, add-on capture 
definitions 120, add-on capture handlers 1 12, add-on action handlers 114, capture storage 
manager 116, capture persistent storage 130, persistent storage 128, web interface 122, 
web access 124, and Java graphical user interface (GUI) 126. 

[0019] The sensors 102 include components representing an extensible set of 
applications, including device drivers plus hardware sensors, user-mode applications that 
communicate with sensors through network or other high-level protocols (modbus, 
proprietary RS-232/485, SNMP, common information model (CIM)), or application- 
based instrumentation, such as data reported by application servers. These sensor 
applications 102 interact with the data management system 104 in two ways. 

[0020] First, the sensor applications 102 "publish" descriptions of the instances of the 
sensors that exist, including data such as presentational labels, sensor type, units of 
measurement, range, value increment size, suggested threshold settings, suggested value 
formatting data, and data to aid in mapping the sensor output to various management 
protocols (such as SNMP). 

[0021] Second, the sensor applications 102 report updates to the current value and status 
of each sensor that has been published. In one particular embodiment, sensor values are 
reported in an event-driven manner when they differ from the previous values reported. 
Event driven reporting improves system scalability, and allows the other applications to 
assume that a sensor's value is unchanged until an update has been reported. This 
method also removes the overhead involved in polling sensor values continuously. In a 
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particular implementation, an example of the data published for a typical sensor is shown 
in Appendix A (encoded in XML). 

[0022] The sensor applications 102 also may make use of data persistence features of the 
data management system 104, allowing sensor definitions to contain customizable and 
non- volatile settings, such as user-custom labels, and configuration data to assist the 
sensor application 102 with "re-associating" a sensor object reported to the physical 
sensor during system restart. For example, the data may include correlations between 
one or more USB-attached sensor pods and corresponding sensor objects previously 
stored in the data manager 104. 

[0023] In a particular embodiment, the data management system 104 is a shared variable- 
space system, which may be implemented using data systems, such as the Windows 
Registry, a lightweight directory access protocol (LDAP) directory server, or other data 
management system. In an illustrative implementation, a lightweight custom system 
may be implemented using a kernel-mode device driver. This implementation allows for 
fast and efficient interaction with shared data from both other kernel-mode drivers, such 
as those used for driving add-on sensor hardware, and applications, such as SNMP-based 
management applications. The data management system 104 also includes a persistence 
mechanism that automatically stores objects that are declared to be "persistent" when 
registered and restores such objects after system restart. For example, the data 
management system 104 may store some variables in persistent storage 128. In addition, 
the data management system 104 may provide both programming to read the values of 
the objects and programming to "listen" to the objects, particularly sensors, so that sensor 
value updates are quickly received and available for processing. 

[0024] The monitoring/policy subsystem 106 provides monitoring logic and algorithms 
for the appliance. Specifically, the subsystem 106 "listens" to the data manager 104 for 
updates on sensor values and updates to algorithm configuration data, and passes this 
update data into an event-driven logic engine that ultimately produces error condition 
objects. Error condition objects contain data to describe the occurrence of a problem. 
For example, an error may be detected based on a violation of thresholds implemented by 
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the policy engine and its configuration. Error condition objects are created when a 
problem is detected and set to a "resolved" state when the problem is no longer indicated. 
These error condition objects, also referred to as "alerts," are published to the data 
management system 104, allowing access by other applications, such as the alert handling 
subsystem 1 10. An exemplary embodiment of a published error condition, encoded in 
XML, is shown in Appendix B. 

[0025] The add-on policy class definitions 108 are XML-encoded definition files, 
optionally supplemented by custom code delivered in shared libraries (DLLs, or .so files) 
that describe additional alert logic blocks. 

[0026] In a particular embodiment, the base monitoring system 106 includes a number of 
standard logic block primitives. These logic blocks may include: 

• Boolean logic primitives, such as logical AND, OR, NOT, time delay 
elements (output = input as of N seconds ago), and hysteresis elements 
(output = input once input has been set for at least N seconds) 

• Numeric primitives, such as add, subtract, multiply, divide, time delay 
elements (output = input as of N seconds ago), hysteresis elements (output 
= input once input has been set for at least N seconds), bounding elements 
(output = input, constrained to a defined range), comparison elements (A 
>= B, etc), min-max elements (output = min(all inputs), output = max(all 
inputs)), and min-max over time elements (output = max(input over last N 
seconds)). 

• Time primitives, such as schedule blocks (output=true when time is 
configured time of day/day of week). 

• Error reporting primitives, such as blocks to generate/resolve error 
conditions when their inputs are 'true' (either in general, or for the sensor 
associated with a specific input). 

[0027] In addition, the monitoring system 106 supports defining "composite blocks", 
consisting of a logical network of other blocks, used to derive a complex function block. 
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The monitoring system 106 provides a number of such composite blocks, providing the 
following logic types, among others: 

• Range thresholds (generate error if sensor is above a given value A or 
below a given value B) 

• Minimum value thresholds (generate error if sensor is below a minimum 
value A) 

• Maximum value thresholds (generate error if sensor is above a maximum 
value A) 

• Minimum value for time thresholds (generate error if sensor is below a 
minimum value A for longer than time T) 

• Maximum value for time thresholds (generate error if sensor is above a 
maximum value A for longer than time T) 

• Rate of increase thresholds (generate error if value of sensor increases by 
more than N in the last T seconds) 

• Rate of decrease thresholds (generate error if value of sensor decreases by 
more than N in the last T seconds) 

• Invalid state thresholds (generate error if value of sensor is equal to value 
X - used for Boolean and discrete state sensors) 

• Invalid state for time thresholds (generate error if value of sensor is equal 
to value X for longer than time T) 

• State Mismatch Threshold (generate error is value of sensor is not equal to 
value X - used for Boolean and discrete state sensors) 

• State Mismatch for time Threshold (generate error is value of sensor is not 
equal to value X for longer that time T) 

[0028] Additional blocks can be defined by providing an XML-encoded file containing 
the definition of the block, by describing which other blocks to create and how to 
interconnect these blocks. An exemplary XML grammar that may be used in a particular 
implementation can be found in Appendix C. 
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[0029] Each block class, whether primitive (implemented using native code) or 
composite (implemented by combining other blocks based on an XML-provided class 
definition), may include: 

• Parameters - these are configuration parameters, such as threshold limits, 
labels, timing data, and such, that are provided in order to define the 
desired behavior for a block of the class. In object-oriented programming, 
these would be defined as "instance variables" of the class. Each 
parameter definition includes a data type. For example, the parameter 
definition may include both a general type, such as integer, string, floating- 
point, and Boolean, and a specific subtype, such as an indicator that a 
string parameter is an IP address or a list of e-mail addresses, a label, a 
default value, a classification (basic or advanced), a units indicator, and 
references to limits on a parameter's value. Limits may , for example 
include explicit limits, limits based on the limits of a sensor associated with 
one of the inputs of the block, or limits based on the value of other 
parameters of the block. 

• Inputs - these are input "signals" to the block, which are tied to a signal 
source. The signal source may, for example, be a sensor, or the output of 
another block. The definition includes a data type indicator, a label, and 
constraints on what classes of signal source can be used. The constraints 
on the signal source limit possible input sources to appropriate types of 
sensors. For example, a block particular to processing temperature 
readings might constrain its input to the class of objects representing 
temperature sensors. 

• Input Sets - these are "lists" of similar inputs, which support having zero 
or more signals attached to them. Input sets are typically used like normal 
inputs, but for situations where the number of inputs is variable, such as the 
inputs to a block, which simply reports the maximum value among an 
arbitrary set of inputs. Each input set defines a label, data type, and a 
minimum and maximum number of signals. 
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• Outputs - these are "signals" produced by the block, which may be tied to 
the inputs of other blocks. The definition includes a data type and a label. 

[0030] Composite block classes may also include a description of a set of block instances 
created to implement a block of the class, the interconnects between those block 
instances, and the outputs and inputs of the block to be defined (both input and output 
signals, as well as mappings of parameter values from the "parent" block into the 
"embedded" blocks that implement it). An example of a composite block definition is 
provided in Appendix D. 

[0031] The data contained in the block definitions, in addition to providing the functional 
information for the monitoring subsystem 106 to create and manage the blocks associated 
with the class, also provides presentational information for the configuration tools to 
create or edit block instances. In a particular implementation, Java based GUI tools may 
be implemented that access data through an XML-encoded HTTP interface on the 
appliance. The data provided in the class definitions is used to generate the GUI 
interfaces dynamically, allowing new block classes to be added to the system without 
requiring custom development on the GUI tools. 

[0032] Another use of composite block classes is to provide new sensor readings that can 
be "synthesized" from one or more existing readings. An exemplary synthesized reading 
is a block that takes inputs from a temperature sensor and a humidity sensor and produces 
an associated sensor reading that describes the vapor pressure of water. 

[0033] The alert handling subsystem 1 10 is responsible for driving responses to error 
conditions reported by the monitoring subsystem 106 or other sources. For example, the 
alert handling subsystem 110 "listens" to the data manager 104, responding to error 
conditions created or updated within the data manager 104. The alert handling subsystem 
110 may also listen to the data manager 104 in order to receive its configuration 
information, particularly with respect to alert profiles and alert actions. 

[0034] In a particular embodiment, the alert handler subsystem 110 implements the 
response to an error condition by following a procedure described by objects, such as 
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alert profiles. Each alert profile defines a set of one or more response sequences. Each 
sequence defines a set of alert actions to be taken, the time after the beginning of the alert 
to execute the actions for the first time, the interval between this time and repeated runs, 
and a maximum number of repeated runs. These sequences may be used to implement 
escalation policies: allowing the system to run one set of actions when an error condition 
first occurs, a different set if the condition is still unresolved after a period of time, and 
additional actions at an even later time. Also, it allows some actions to happen 
repeatedly at different rates. An example of a set of sequences in an alert profile might 
read: 
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[0035] 

Sequence 1: at T=0 sec, repeating 3 times every 300 sec, do: 

Send E-mail to Fred 
Sequence 2: at T=1200 sec, repeating 5 times every 1200 sec, do: 

Page Fred and George 
Sequence 3: at T=7200 sec, repeating 0 times, do: 

Turn on alarm siren 

Page Fred's Boss 
Sequence 4: at T= sec, repeating 1000000 times every 60 sec, do: 

Send SNMP trap to Net View 

[0036] This exemplary set of sequences would result in a sequence of actions, starting 
with Fred getting an e-mail as soon as a problem was detected and every 5 minutes until 
the problem is either resolved or until 15 minutes have passed. After 20 minutes, if the 
problem is still unresolved, both Fred and George get paged, and get paged again every 
20 minutes until 2 hours have passed or the problem is resolved. After 2 hours, if the 
problem is still unresolved, an alarm siren is triggered and Fred's Boss gets paged. In 
parallel with this escalation, SNMP traps have been sent once per minute from the time 
when the problem first occurs. 

[0037] A particular embodiment of an action profile also includes support for enabling 
and disabling sequences, based on a schedule, such as the time-of-day and day-of-week. 
The feature may operate by not taking the prescribed actions if the time that those actions 
would occur does not match the constraints of the schedule. In addition, alternate 
sequence may be defined to better align with work shifts, for example. In the above 
example, one might make "Sequence 1" constrained to M-F, 7AM-7PM, for example, 
when Fred is on call, and add "Sequence la" for M-F 7PM-7AM which e-mails George, 
for example, when George is on call. An example of a profile definition, in XML format, 
is shown in Appendix E. 
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[0038] Each of the actions referred to by an alert profile ("Send e-mail to Fred") is 
defined by an alert action object. Each alert action object is an instance of a general 
action handler ("Send E-mail") defined by an alert action class object. Alert action class 
objects are registered with the alert handler subsystem 1 10, for example through XML- 
encoded registration files, and may be processed by invoking add-on executables, such as 
those indicated by the registration files. 

[0039] Alert action objects, when configured, can be defined to request the capture of 
additional data supporting the alert before they are invoked. In a particular 
implementation, the data may include image files showing graphs of the value of the 
sensor associated with the alert, audio clips captured from one or more microphones 
accessible to the appliance, and picture sequences captured from one or more cameras 
accessible to the appliance. Sensors or cameras accessible to the appliance may be 
integrated, attached or accessible via wired or wireless communication. These capture 
choices are driven by several factors: 

• What capture handlers are available and configured? For example, is the 
picture capture handler available, and which cameras have a configuration 
defined to have pictures captured (how many, at what rate and at what 
resolution)? 

• Which objects were associated with the alert being processed by the 
threshold that generated the alert (for example: Which sensor? Which 
cameras? Which microphones?)? 

• What types of captured data are supported by the alert action? For 
example, SNMP traps cannot send pictures or graphs, but the e-mail action 
handler can. 

[0040] Based on these factors, each alert action that is triggered as part of alert handling 
will yield zero or more "capture actions" that are to be executed before the given alert 
action has the desired information. The alert handler subsystem 110 may invoke the 
desired capture actions and invoke alert actions that do not use data from the capture 
actions. The capture actions may include those defined on the appliance or those defined 
on other remote appliances. The alert actions can include data captured by these actions, 
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whether remote or local. As the capture actions complete, the alert actions that utilize the 
captured data may be invoked, such as when captured data requested is available. 

[0041] The alert handler subsystem 110 also keeps track of alert actions that have been 
invoked at least once for the sake of a given error condition. When the error condition 
becomes "resolved", the alert handler subsystem 1 10 may invoke each of these actions 
one last time, such as with a parameter indicating "return-to-normal" versus "error", 
allowing the actions to report the appropriate "problem resolved" situation. 

[0042] In an exemplary embodiment, alert actions support a variety of parameters for 
controlling whether they are to be executed. Specifically, each alert action instance may 
have a schedule to control whether it is enabled or disabled by time-of-day and day-of 
week. Also, each alert action may be configured to be triggered for error conditions of 
specific severities. An exemplary implementation supports a 5-level severity scheme: 
information, warning, error, critical, and failure. The severity, for example, may be 
defined by the logic creating the alert or error object. 

[0043] For certain captured data, such as camera pictures, it may be desirable to capture 
and store more data than may be practical or desirable to transmit. For example, capturing 
5 frames per second of video of an intrusion may be appropriate, but sending 30 seconds 
of such video (150 frames, which would likely be several megabytes of data) would be 
inappropriate for most e-mail systems. To handle this, the alert actions may support 
configuring limits on the amount of data that the action should actually process 
independent of how much is actually captured. Specifically, the action can be configured 
to include up to N of the pictures that were captured where N is, for example, user- 
settable. The alert actions can process this data, and use it to select a subset of the data 
captured. If N=10 and 150 pictures are captured, every 15 th frame may, for example, be 
included in the e-mail. By having configuration control, the system can send appropriate 
levels of information through the different notification mechanisms. For example, the 
system may capture 150 pictures and send all of them to an FTP server for archiving, 
while sending a sampling of 10 of them to an administrator through e-mail. 
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[0044] In an exemplary embodiment, the alert handler subsystem 1 10 is informed of the 
types of data that may be captured and the particulars on how to invoke executables to 
implement those captures through capture definitions, such as add-on capture definitions 
120 (e.g. an XML-encoded registration file). Each add-on capture handler definition 120 
provides a file, which may contain data such as the name of the executable, such as add- 
on capture handlers 1 12, to be invoked (whether a shared library and entry point to be 
called "in-process*' or an executable to be run as a separate process), concurrency limits 
(how many captures of this type can/should be allowed to run at one time), which types 
of objects these captures are "tied to" (picture captures may be defined relative to a 
camera object, graphs to a sensor, audio clips to a microphone), and what parameters 
need to be defined to specify the capture (number of frames, frame rates, etc). 

[0045] The alert handler subsystem 110 may use the information in the add-on capture 
handler definition files 120, coupled with the capture configuration settings based on 
these files and provided by the user, to invoke the capture handler executables 112 when 
a data capture is requested. When invoked, these executables are provided with the 
object ID of the capture source "tied to" them (i.e. the camera tied to the capture 
configuration), the error condition object causing the capture, as well as the alert action 
and alert profile associated with the handling of the capture. The capture handler 1 12 
uses this data to determine how to process the capture. The capture handler 112 captures 
the requested data and stores the data into the capture storage 128 through the capture 
storage manager 116. For example, the capture storage manager 116 may store captured 
data in the capture persistent storage 130. Once stored, the capture handler 112 creates a 
special object that describes the data captured, and includes information to retrieve the 
data from the capture storage manager 116. 

[0046] In a particular embodiment, the alert handler subsystem 1 10 is informed of the 
types of notification actions that may be taken, and how to invoke the executables needed 
to implement those actions through action handler definitions, such as add-on action 
handler definitions 118, which may be an XML-encoded registration file. Each alert 
action handler definition provides a file that may contain data such as the name of the 
executable, such as an add-on action handlers 1 14, to be invoked (whether a shared 
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library and entry point to be called "in-process" or an executable to be run as a separate 
process), concurrency limits (how many captures of this type can/should be allowed to 
run at one time), which types of capture can be processed by the action, and what 
parameters need to be defined to specify the action (e-mail addresses, URLs, etc). An 
example of an add-on action handler registration object is provided in Appendix F. 

[0047] The alert handler subsystem 110 may process alert actions by invoking the 
executables defined by the alert action handler definitions 118 associated with the alert 
action class of the action to be run. These executables, such as add-on action handlers 
1 14, which may be in-process shared-libraries or separate processes started by the alert 
handler subsystem 1 10, are passed information including the object ID of the error 
condition, alert action, and alert profile objects driving their invocation. This information 
may be used by the action handler executable to access the necessary objects in the data 
manager 104 to provide the data needed to process the action. If the action is configured 
to process captured data, the action handler, such as add-on action handler 1 14, 
enumerates the captured data objects that are associated with the activation of the alert 
profile for the given error condition, and retrieves the data from the capture storage 
manager 1 16. An example of the configuration of an alert action handler definition is 
provided in Appendix G. 

[0048] Action handlers may include executables, scripts, and programs configured to 
perform one or more functions such as email, FTP, HTTP POST, SMS, SNMP, audio 
output, pager output, telephonic output, controlling digital or analog outputs, and 
switching power on/off. An illustrative implementation provides a number of default 
alert action handlers configured to perform the following: 

[0049] Sending E-mail generates a plain text or HTML-encoded e-mail to a desired set of 
recipients, such as those provided through the action configuration and provided by the 
policy subsystem 106 through the error condition. The e-mail may include a link back to 
the monitoring appliance, allowing the recipient to browse to the appliance and 
specifically, to a web page providing a real-time status of the error condition and to 
capture data associated with the error. The e-mail may include graphs of sensor data 
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associated with the error, picture sequences from one or more cameras, and audio clips 
from one or more microphones. The action may support utilizing one or more backup 
SMTP servers, so that failure to deliver to the first SMTP sever results in a transparent 
fail-over to delivering through the backup(s). Delivery using encrypted and secure 
STARTTLS and SSL-based encrypted extension to SMTP may also be provided. 

[0050] Sending FTP generates and transfers an XML-encoded file describing the error 
and the objects associated with the error (sensors, pods, etc) and uses the FTP protocol to 
transfer this file to an FTP server. The action may also deliver picture files, audio clip 
files, and graph image files that have been captured. The action may be configured with 
additional backup FTP servers, allowing fail-over to those servers in the event that the 
files cannot be transferred to the provided FTP server. 

[0051] Sending HTTP POST generates and transfers files, such as an XML-encoded file, 
describing the error and the objects associated with the error (sensors, pods, etc) and uses 
the HTTP protocol to transfer this file to a web server, for example, as part of a 
"multipart/form-data" encoded HTTP transfer similar to the sort of transfer done by a 
web server when submitting FORMS that include FILE input parameters. The action 
may also deliver picture files, audio clip files, and graph image files that have been 
captured. The action can be configured with additional backup HTTP servers, allowing 
fail-over to those servers in the event that the files cannot be transferred to the provided 
HTTP server. Support for HTTPS, including various degrees of certificate authentication 
and exchange of client certificates, may be included. 

[0052] Sending SMS e-mail generates a short, plain-text e-mail suitable for SMS devices 
(pagers, cell phones, PDAs) or other devices where small message size is preferred. The 
action supports fail-over and encryption features similar to the Send E-mail action. 

[0053] Sending SNMP Trap, for example, generates an SNMPvl encoded trap and 
transmits it to an SNMP manager at a given address. The SNMP enterprise object 
identification (OID) may be provided by data from the alerting object (sensor type or 
pod), and the enterprise specific type is provided by the alert type object. 
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[0054] Playing audio generates an audio message, and may play the audio message over 
a set of speakers attached to an audio output. The message may be generated by 
concatenation of a set of prerecorded message clips. A particular implementation uses a 
set of clips for each severity ("Information", "Warning", etc), followed by a set of clips 
for the different sensor and object types generating the alarm ("Temperature", 
"Humidity", "Sensor Pod", etc), followed by a set of clips for the different error types 
("Too High", "Too Low for Too Long", "Unplugged", etc), followed by the message 
"Problem Resolved" when the error is resolved. An example message would be "Error. . . 
Temperature. . . Too High", or "Warning. . . Sensor Pod. . . Pod Unplugged". The action 
may support selecting on which audio outputs to play the message, and with what 
volume. The system may support adding new audio clips as part of adding new sensors 
or new alert types. 

[0055] The capture storage manager 1 16 manages the memory 130 allocated to the 
storage of captured data. This storage can take different forms (possibly Flash, RAM, or 
magnetic media), and can be of varying sizes. In one particular implementation, the 
storage 130 for the capture data may be provided using a RAM-based file system or a 
traditional file system based on a USB-attached hard drive. The capture manager 116 
provides an interface to access this storage, for example, for the sake of creating and 
writing sets of capture data to the storage, and for retrieval of this data from storage. The 
capture storage manager 116 may provide several features, such as an abstraction, similar 
to a file system, to shield the other applications from the particulars of the different 
mechanisms of storage that may be implemented. 

[0056] The capture storage manager 116 manages the data stored within the storage, 
discarding data as new data demands additional space. Specifically, when new data is 
being captured, the capture manager transparently handles conditions when the storage is 
exhausted, for example, implementing an "age-out" algorithm that deletes the oldest 
unused data captures from the storage in order to make room for the new data. Alternate 
algorithms, such as ones sensitive to error state (resolved versus unresolved), severity, 
data size, or combinations of the above, can easily be employed by the capture storage 
manager 116. The capture storage manager 1 16 monitors the deletion of error conditions 
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that "own" the captured data, and cleans up the data accordingly. The capture storage 
manager 116 may also provide a locking mechanism for captured data, allowing 
applications such as web interfaces, to "open" a set of captured data and read portions of 
the data safely by preventing deletion of the data while the records are open. 

[0057] The capture storage manager 116 may provide support for recognizing duplicate 
data records provided by different capture handlers 112 and may prevent duplication of 
the data stored. In a particular implementation, this is accomplished by using strong hash 
codes (such as MD5) for each data object, recognizing duplicates by keeping a cache of 
hash-codes versus recently stored objects, and storing the data in a file system supporting 
hard-linking so that, for example, the duplicated data can be stored in a single i-node 
while still being referred to by two or more different hard-links. 

[0058] The system may provide a set of HTML-based web interfaces 122 or 124 for 
accessing the status of the sensors monitored by the device and for allowing access to 
summaries of the error conditions, the details of each error condition, and the captured 
data associated with these conditions. The interfaces may be provided using CGIs that 
generate HTML documents using data acquired by querying the data manager 104 and 
the capture manager 116. Examples of the interfaces are provided in FIG. 2 through FIG. 
15. 

[0059] FIG. 2 shows an exemplary interface depicting the display of camera image data. 
Data associated with a monitoring system, including sensor data and alarm status, is 
shown on the left. Optionally, a tree structure may be provided for selecting pods and 
other devices, as shown in the upper left corner of the exemplary interface. Image data 
may be interchanged by selection of another camera from the drop-down menu or a 
thumbnail or small image located below the presently selected camera image. In 
addition, other data views may be accessed via tabs located, for example, at the top of the 
page, such as camera, alerts, graphs, setup, and about tabs. 

[0060] FIG. 3 depicts an exemplary summary of alerts for a monitoring system. A table 
of alerts is shown for sensor devices, such as sensor pods, associated with the monitoring 
system. Alternately, the table may be subdivided by pod through selection of an item in a 
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drop-down menu. Specific alert details may be accessed through links, such as links 
associated with the description. 

[0061] FIG. 4 shows an exemplary interface depicting alert details for a selected alert. 
Alert details may include a description of the alert, alert type, time detected, time 
normalized, severity, current values, and identifiers for the pod, error type and error 
objects. The alert details may provide a link to captured data associated with the alert, 
such as, for example, data links listed below the alert details. The captured data may, for 
example, include graphs, audio and video data. FIG. 5 depicts an exemplary interface 
having the captured data, in this case, a graph of temperature. 

[0062] FIG. 6 depicts an exemplary details interface for another alert. In this exemplary 
embodiment, the captured data includes a sequence of pictures. FIG. 7 shows an 
exemplary interface for accessing these pictures. An interface is provided to play the 
images sequentially or to select a desired image. 

[0063] FIG. 8 illustrates an exemplary interface for configuring alert actions. Alert 
actions may include sending data, such as via FTP, email, SNMP traps, HTTP posting, 
and SMS. Alert actions may also include playing an audio alert via a local speaker or 
generating an audio message. An alert action may be added, edited, or removed through 
this interface. If "add" is selected, an exemplary interface as depicted in FIG. 9A may be 
displayed. Once an alert action is selected, configuration data may be entered and 
associated with the action through an exemplary interface, such as that shown in FIG. 9B. 
The alert action may include settings regarding the amount and type of data to be 
transferred, advanced scheduling, error severities to which the alert may apply, and 
addressing data. FIG. 9B depicts exemplary addressing information for an FTP transfer. 

[0064] Alert actions are often accessed by alert profiles. Alert profiles generally detect 
error objects and determine which alert actions should be applied. Alert profiles may be 
configured with an interface, such as the exemplary interface shown in FIG. 10. Alert 
profiles may include a sequence of triggers, termed alert profile sequences. The alert 
profile sequences may be labeled and provided with a start time, number of repeats and 
interval between repeat. For example, the start time may be a time relative to the 
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detection of an error object, such as 0 minutes, 20 minutes, or 90 minutes. The actions 
associated with the profile may be performed once, more than once, or continuing until 
the error is resolved. Scheduling and alert sequences may be added, edited, or removed. 
For example, alert sequence configurations may be added as shown in the exemplary 
interface of FIG. 1 1 . The alert profile sequence is provided with timing data and 
associated actions. 

[0065] Alert profiles are triggered based on the detection of an error object. The error 
object may be created by a monitoring subsystem in response to a change in a sensor 
value and registered with the data management system. Sensors, pods, or other data 
objects may be registered with the data managements system and the monitoring 
subsystem. For example, sensor pods may be configured through an interface such as 
that of FIG. 12. Available sensors may be selected, configured, and provided with 
conditions that result in the creation of an error object. These conditions (in this 
exemplary embodiment, thresholds) may be added using the exemplary interfaces of 
FIGs. 13 A and 13B. FIG. 13A depicts the selection of a threshold and FIG. 13B depicts 
the configuring of a threshold. Advanced threshold configuration is depicted in the 
exemplary interface of FIG 14 and may provide for advanced scheduling and capturing of 
data. For example, a list of cameras is provided in FIG. 14. 

[0066J An advanced scheduling interface may also be provided. For example, FIG. 15 
depicts a weekly scheduling calendar for enabling and disabling the threshold schedule. 
Such a scheduling interface may also be provided for alert profiles, alert profile 
sequences, and alert actions. 

[0067] In an alternate embodiment, condition logic may be provided through add-on 
policy class definitions 108. These definitions may provide for complex definitions 
utilizing one or more simple blocks. Add-on policies may, for example, utilize threshold 
block and conditional blocks to determine error severity. In addition, alert actions and 
capture definitions may be provided, such as through XML documents. 

[0068] Turning to FIG. 1, these interfaces may be implemented through the web interface 
122, web access 124 and JAVA GUI 126. Similar exemplary interfaces may be 
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supported for use in a centralized, mass-configuration and mass-management oriented 
product. As with the appliance's Java GUI 126, a centralized product may use the Web 
Access interfaces 124 to acquire and manipulate the appliance status and configuration. 
In the case of the centralized product, the design may use a 3-level scheme, with a Java 
GUI communicating with the management server, which then communicates with the 
appliance on the GUI's behalf. 

[0069J Turning to FIG. 16, once sensors, condition logic, alert profiles, profile 
sequences, alert actions, and capture definitions are configured, the system may operate 
to post changes to data such as through a data journal and take action in response. For 
example, the monitoring subsystem may detect an update to a sensor value as posted in 
the data management system, as shown at step 1602. The policy or condition may 
determine an error state in response to the sensor value update, as shown at step 1604. If 
an error state exists, an error object or alert may be created or a state of the error object 
may be changed, as shown at step 1606. For example, a threshold may be violated and an 
error object created and registered with the data management system. The error object 
may include, for example, an error status, an error start time, error level, and other 
associated data. 

[0070] The alert handling subsystem may detect the error object, as shown at step 1608. 
The alert handling subsystem may access an alert profile and associated alert sequences 
to determine an alert action, as shown at step 1610. For example, the alert profile may 
include a continuous sequence element that provides for sending an SNMP trap and 
playing an audio message. Alternate embodiments of alert actions may include captured 
data. For example, FTP alert actions may transfer image data. As a result, the system 
may optionally capture data, as shown at step 1612. If captured data is desired, the alert 
action may delay performance until the data is available. For example, the capture 
management system may capture and store data and notify the alert action of data 
availability. The action may be performed, as shown at step 1614. 

[0071] Errors and alerts are often responsive to changes in sensor values. In alternate 
embodiments, alert profiles and the alert handling system may act on changes to sensor 
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values in the data management system. For example, door alarms, motion detectors and 
other anti-theft alarms may be bi-state sensors (on/off, true/false). The alert profiles may 
be configured to act based on a change in state, such as a door opening or a lost 
connection. 

[0072] Generally, errors may be resolved. For example, a temperature threshold 
violation may be resolved once air conditioning is restored. As shown in FIG. 17, the 
monitoring system may detect an update, as shown at step 1702. The monitoring system 
may determine that the error has been resolved, as shown at step 1704, such as the 
temperature no longer violating a threshold. The monitoring system may change the state 
of the error object to "resolved," as shown at step 1706. The alert handling system may 
detect the error object state, as shown at step 1708, and adjust the behavior, as shown at 
step 1710. For example, the system may send an error resolved notification and cease 
further action. A similar method may be used to change the severity level of the error 
object. For example, the error object may have one severity level while the sensor value 
is below a first threshold, another level when the sensor value violates the first threshold 
but remains below a second threshold, and a further level when the sensor value violated 
the second threshold. Severity may also be determined via advanced policies utilizing 
more than one sensor input and comprising conditional terms. 

[0073] FIG. 18 depicts an exemplary embodiment of a monitoring appliance 1802. The 
monitoring appliance 1802 may include interfaces to sensors 1806 and cameras 1808 to 
monitor the space 1820 and environment about equipment 1810. Exemplary sensors 
1806 may include temperature sensors, airflow sensors, microphones, humidity sensors, 
motion sensors, door sensors, and leak detection sensors. Cameras may be used to 
monitor activities within the space. In addition, cameras and microphones may be used 
to monitor external signals provided by equipment and alarm systems. In one exemplary 
embodiment, the monitoring appliance 1802 may also include a connection to equipment 
1810 for monitoring equipment operations, such as through SNMP. 

[0074] The monitoring appliance 1 802 may also communicate with a remote system 
1812, such as a telephonic system or interconnected network system. For example, the 
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monitoring appliance 1802 may communicate with a remote system connected to a pager 
network or telephonic network. Alternately, the monitoring appliance 1802 may 
communicate with a server via a protocol such as HTTP, FTP, or SNMP. 

[0075] In one particular embodiment, the monitoring appliance includes a journaling data 
system 1804, which may act as a data manager. A monitoring system 1814 may interact 
with data in the data system 1804 to detect error conditions. The monitoring system 1814 
may create error objects. These error objects may be used by an alert system 1 8 1 6 to 
determine and facilitate actions in response to the error object. The actions may include 
capturing additional data such as image data, audio data, data from other accessible 
appliances, and data from accessible sensors. In exemplary embodiments, sensors, 
cameras, and other appliances may be accessed via wired or wireless connections. In one 
exemplary embodiment, sensors and a camera may be integrated with the appliance. 

[0076] In an exemplary embodiment, the monitoring appliance may function to detect a 
problem and, when the problem occurs (threshold violation, sensor failure, etc), capture a 
set of video-quality pictures (high framerate) while sending only a couple of those 
pictures using e-mail. The person notified via e-mail receives a smaller, more 
manageable e-mail that can be used to evaluate whether the details of the video should be 
reviewed. The video-quality pictures may be transferred using FTP or HTTP to a server 
for long-term storage. 

[0077] In another exemplary embodiment, device may use multiple thresholds on a given 
sensor to allow distinction between minor/less severe events (i.e. temperature slightly 
exceeding norms) versus more severe events (i.e. temperature rising very quickly, or 
exceeding norms by a large margin). The device may use either severity on each 
threshold or use different alert profiles on each thresholds to control which actions are 
triggered in response. 

[0078] In a further exemplary embodiment, the device may use schedules on different 
alert actions to allow the same profile to be used to notify different people (possibly using 
different mechanisms), based on work schedules (i.e. who is responsible for handling 
such problems at specific times of day/days of week). The device may use different 
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sequences in a profile to allow "escalation" of an unresolved problem, by triggering more 
urgent notification mechanisms (i.e. pagers versus e-mail), notifying different persons 
(i.e. backup, management), and/or taking corrective action (i.e. turning off power, turning 
on backup cooling). In a further exemplary embodiment, the device may use schedules 
and multiple thresholds in order to allow different "acceptable" values or behaviors at 
different times of day/days of week. 

[0079] In another exemplary embodiment, the device may have the ability to have any 
single threshold or error-generating function drive collection of video and/or audio from 
zero or more cameras simultaneously, allowing correlated data collection from multiple 
vantage points. 

[0080] In an exemplary embodiment, the device may include support for (using multiple 
alert profiles) distinctive response for different types of sensors (environmental versus 
security versus network), including different notifications to different people. 

[0081] In an exemplary embodiment, the device may include support for add-on actions 
for communicating notifications into 3rd party systems, such as trouble-ticketing systems, 
databases, and system and network management products. 

[0082] In an exemplary embodiment, the device may include support for 
communications failover during alert notifications, such as activating a modem when 
attempts to use network communications fail, allowing notifications to be successfully 
delivered. In a further exemplary embodiment, the device may include support for alert 
actions that issue commands to output devices, including changing the states of switches 
(including power switches) or causing switches to change state for a defined period of 
time. In another exemplary embodiment, the device may include support for threshold 
types that require human interaction before a detected problem is reported as "resolved". 
In an exemplary embodiment, the device may include support for threshold types that 
would monitor and check the values of more than one sensor, possibly of different types, 
and generate error reports based on a combination of conditions on the monitored 
sensors. In another exemplary embodiment, the device may include support for delivery 
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of alert data, including captures pictures/audio/etc to multiple locations for the sake of 
security and/or redundancy. 

[0083] The above-disclosed subject matter is to be considered illustrative, and not 
restrictive, and the appended claims are intended to cover all such modifications, 
enhancements, and other embodiments, which fall within the true scope of the present 
invention. For example, the system and methods may be implemented in embedded 
systems such as monitoring appliances, as well as in PCs and servers systems. Thus, to 
the maximum extent allowed by law, the scope of the present invention is to be 
determined by the broadest permissible interpretation of the following claims and their 
equivalents, and shall not be restricted or limited by the detailed description including the 
APPENDIX. 
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APPENDIX 

Appendix A: Sample Sensor Description in XML 

<variable varid= M nbHawkEnc_0_TEMP" guid= M B029f51_nbHawkEnc_0_TEMP" 
classpath=7nbSensor/nbNumSensor/nbTempSensor" val-transient= n yes" 
persistent="yes" readonly="no" constant= ,, no" remote="no" globaIid="no n 
nodelete="no"> 

<double-val isnull="no">27.200000</double-val> 

<metadata slotid="nbSortPrio M isclassdef="yes"> 

<i32-val isnull= ,, no">10</i32-val> 

</metadata> 

<metadata slotid="nbUnitsID" isclassdef="yes"> 
<varid-val isnull="no">nbUnits_DegC</varid-val> 
</metadata> 

<metadata slotid="nbSugThreshCls" isclassdef="yes"> 
<varid~val isnull="no">nbPlcyCls_nbRangeThresh</varid-val> 
</metadata> 
<metadata slotid="nbMinVal" isclassdef="yes"> 
<double-val isnull="no">-40.000000</double-vai> 
</metadata> 

<metadata slotid="nbMaxVal" isclassdef="yes"> 
<double-val isnull="no">50.000000</double-val> 
</metadata> 
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<metadata slotid="nbValInc" isclassdef="no"> 
<double-val isnull="no">0.100000</double-val> 
</metadata> 

<metadata slotid="nbPrintfFmt" isclassdef="yes H > 
<string-val isnull="no">%.lf</string-val> 
</metadata> 

<metadata slotid="nbHistoryTime" isclassdef="yes"> 
<u32-val isnuil= ,, no">28800</u32-vai> 
</metadata> 

<metadata slotid = "nbSNMPEnterpriseOID" isclassdef="yes"> 

<string-val isnull="no M > 1.3.6. 1.4.1.5528.100.10.2.1 </string-val> 
</metadata> 

<metadata slotid="nbAudioC!ipID" isclassdef="yes"> 

<varid-val isnull="no">nbAudioClip_temperature</varid-val> 
</metadata> 

<metadata slotid="nbSimpleThreshDer isclassdef= ,, yes"> 
<varid-list-val isnull = "no"> 

<varid-val isnull="no">nbSimpleThreshPlcyBlkDef_temp</varid-val> 
</varid-list-val> 
</metadata> 

<metadata slotid="nbSimpleThreshDefDone" isclassdef= f, no"> 
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<varid-list-val isnull="no"> 

<varid-val isnull="no">nbSimpleThreshPlcyBlkDef_temp</varid-val> 

</varid-list-val> 

</metadata> 

<metadata slotid= n nbLabel" isclassdef="yes"> 

<nls-string-val raw="%{nbMsg|Temperature%}" 
isnull="no">Temperature</nls-string-val> 

</metadata> 

<metadata slotid= M nbEncID" isciassdef="no"> 

<varid-val isnull="no">nbHawkEnc_0</varid-val> 

</metadata> 

</variable> 

Appendix B: Sample error condition object 

<variable varid="nbErrorCond_4BlF45Bl" guid = "B029f51_nbErrorCond_4BlF45Bl" 
classpath=7nbErrorCond" readonly="no" constant="no" persistent="no" val- 
transient="no" remote="no" globalid= n no" nodelete="no"> 

<struct-val isnull="no"> 

<struct-element fieldid="severity"> 

<string-val isnull= ,, no">fail</string-val> 

</struct-element> 

<struct-element field id ="errortype"> 

<varid-val isnull="no">nbErrorType_podunplugged</varid-val> 
</struct-element> 
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<struct-element fieldid = "enclosure"> 
<varid-val isnull= n no">nbHawkEnc_l</varid-val> 
</struct-element> 

<struct-element fieldid="starttime"> 

<utc-msec-val isnull="no">1050120292428</utc-msec-val> 
</struct-element> 
</struct-val> 
<metadata slotid = "nbDescription" isclassdef="no"> 
<nls-string-list-val isnull="no"> 

<nls-string-val raw="Pod 'Sensor Pod 0002659' is unplugged or has 
malfunctioned." isnull="no H >Pod 'Sensor Pod 0002659' is unplugged or has 
malfunctioned. </nls-string-val> 

</nls-string-list-val> 

</metadata> 

<metadata slotid="nbErrorTypeID" isclassdef= M no"> 

<varid-val isnull= n no n >nbErrorType_podunplugged</varid-val> 

</metadata> 

<metadata slotid="nbErrorResolved n isclassdef="yes n > 
<bool-val val="false" isnull="no" /> 
</metadata> 

<metadata slotid="nbLabel" isclassdef="no"> 
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<nls-string-vai raw="Sensor Pod 0002659 - unplugged" isnull="no n >Sensor Pod 
0002659 - unplugged</nls-string-val> 

</metadata> 

<metadata slotid = "nbEncID" isclassdef="no"> 

<varid-val isnull="no">nbHawkEnc_l</varid-val> 

</metadata> 

</variable> 

Appendix C: XML grammar for custom policy blocks 
<!-- Policy Manager schema, used for encoding custom 
policy classes. ~> 



<!-- Top level object defining a "composite class' (a macro 
class consisting of a network of other class instances), 
'class' is the ID of the defined class, 'label' is 
the NLS-encoded presentation string for the ID (same 
encoding as for 'raw* attributes of <nls-string> in 
nbData.dtd. -> 

<!ELEMENT policy-composite-class ((policy-input-def | policy-input-set-def | 
policy-output-def | policy-parm-def | policy-block-def)*) > 

<!ATTLIST policy-composite-class 
class CD ATA #REQUIRED 
label CD ATA #REQUIRED 
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type (simple-thresh | multi-thresh | primitive | functional-sensor) "primitive'^ 

<!- Policy input definition of a class definition : 'id* is 

identifier of input, 'type' is signal type for input, 

'label' is NLS-encoded presentation string for input -> 
<!ELEMENT policy-input-def EMPTY> 
<!ATTLIST policy-input-def 

id CD ATA #REQUIRED 

type (i32-val | i64-val | double-val | bool-val | string-val) #REQUIRED 
label CDATA #REQUIRED 
class-req CDATA #IMPLIED> 

<!- Policy input set definition of a class definition : 'id' is 

identifier of input set, 'type' is signal type for input set, 

'label' is NLS-encoded presentation string for input set, 

'min-cnt' is minimum number of signals required in set, 

'max-cnr* is maximum number of signals allowed in set. -> 
<!ELEMENT policy-input-set-def EMPTY> 
<!ATTLIST policy-input-set-def 

id CDATA #REQUIRED 

type (i32-val | i64-val | double-val | bool-val | string-val) #REQUIRED 
label CDATA #REQUIRED 
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min-cnt CD ATA "0" 
irax-cnt CDATA ''10000''> 

<!- Policy output definition of a class definition : 'id' is 

identifier of output, 'type' is signal type for output, 

'label' is NLS-encoded presentation string for output. Contains 

a signal reference, defining the source of the output signal. — > 

<!ELEMENT policy-output-def (abs-signal-ref | rel-signal-ref | 

variable-signal-ref | input-signal-ref | input-set-signal-ref)> 

<! ATTLIST policy-output-def 

id CD ATA #REQUIRED 

type (i32-val | i64-val | double-val | bool-val | string-val) #REQUIRED 
label CD ATA #REQUIRED> 

<!-- Absolute signal reference - defines a reference to an output of 
a specific global policy block instance. 

~> 

<!ELEMENT abs-signal-ref EMPTY> 
<!ATTLIST abs-signal-ref 

block-id CDATA #REQUIRED 

output-id CDATA #REQUIRED> 
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<!— Relative output signal reference - defines a reference to an output of 

a relative policy block instance (one defined as part of the composite 

policy block class. — > 
<!ELEMENT rel-signal-ref EMPTY> 
<!ATTLIST rel-signal-ref 

block-id CDATA #REQUIRED 

output-id CDATA #REQUIRED> 

<!-- Variable signal reference - defines a reference to an nb Variable 

as a signal. --> 
<!ELEMENT variable-signal-ref EMPTY> 
<!ATTLIST variable-signal-ref 

var-id CDATA #REQUIRED> 

<!— Relative input signal reference - defines a reference to an input of 

the composite policy block class. — > 
<!ELEMENT input-signal-ref EMPTY> 
<!ATTLIST input-signal-ref 

input-id CDATA #REQUIRED> 

<!— Relative input set signal reference - defines a reference to a signal 
in an input set of the composite policy block class. — > 
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<!ELEMENT input-set-signal-ref EMPTY> 
<!ATTLIST input-set-signal-ref 

input-set-id CDATA #REQUIRED 

input-set-index CDATA #REQUERED> 

<!- Parameter definition for a parameter of a composite class, 'id' is 
ID of the parameter, label' is the NLS-encoded label, 
'advanced' controls if the parameter is an advanced setting, 
'range-from-input' is used to indicate that the units (nbUnits), 
min-val (nbMinVal), max-val (nbMaxVal), and val-inc (nb Valine) 
associated with the parameter value are provided by the 
nb Variable tied to the given input, 'min-from-parm' is used to 
indicate that the minimum value for the parameter is based on 
the current value of the parameter with the provided ID. 
'max-from-parm' is used to indicate that the maximum value for 
the parameter is based on the current value of the parameter 
with the provided ID. 

'units' is used to provide the var-id of the nbUnits object 
describing the units of the parameter 

-> 

<!ELEMENT policy-parm-def (i32-parm-def | i64-parm-def | bool-parm-def | 
string-parm-def | double-parm-def)> 
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<! ATTLIST policy-parm-def 

id CDATA #REQUIRED 
label CDATA #REQUIRED 
advanced (yes | no) "no" 
range-from-input CDATA #IMPLIED 
min-from-parm CDATA #IMPLIED 
rnax-from-parm CDATA #IMPLIED 
units CDATA #IMPLIED> 

<!-- Parameter definition for an int32-type parameter, 'default' is 

default value of the parameter, 'min-val' and 'max-val' are optional 
range restrictions on the parameter. Val-inc' is an optional restriction 
on the interval between valid values. Value can include a list of 
<enum-label> records if it is an enumeration. --> 

<!ELEMENT i32-parm-def (enum-label*)> 

<!ATTLIST i32-parm-def 

default CDATA #IMPLIED 
subtype CDATA #IMPLIED 
rnin-val CDATA #IMPLIED 
max-val CDATA #IMPLIED 
val-inc CDATA #IMPLIED> 
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<!-- Label element for one label of an enumeration: 'label' is the NLS-encoded 

label. -> 
<!ELEMENT enum-label EMPTY> 
<!ATTLIST enum-label 

label CDATA #REQUIRED> 

<!- Parameter definition for an int64-type parameter, 'default' is 

default value of the parameter, 'min-val' and 'max-val' are optional 

range restrictions on the parameter. Val-inc* is an optional restriction 

on the interval between valid values. — > 
<!ELEMENT i64-parm-def EMPTY> 
<!ATTLIST i64-parm-def 

default CDATA #IMPLIED 

subtype CDATA #IMPLIED 

min-val CDATA #IMPLIED 

max-val CDATA #IMPLIED 

val-inc CDATA #IMPLIED> 

<!-- Parameter definition for a boolean-type parameter, 'default' is 

default value of the parameter, --> 
<!ELEMENT bool-parm-def EMPTY> 
<! ATTLIST bool-parm-def 
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default (true | false) "false" 
subtype CDATA #IMPLIED> 

<!-- Parameter definition for a string-type parameter, 'default' is 

default value of the parameter, ~> 
<! ELEMENT string-parm-def EMPTY> 
<!ATTLIST string-parm-def 

default CDATA "" 

subtype CDATA #IMPLIED> 

<!-- Parameter definition for a double-type parameter, 'default* is 

default value of the parameter, 'min-var and 'max-val' are optional 

range restrictions on the parameter. Val-inc' is an optional restriction 

on the interval between valid values. --> 
<!ELEMENT double-parm-def EMPTY> 
<!ATTLIST double-parm-def 

default CDATA #IMPLIED 

subtype CDATA #IMPLIED 

min-val CDATA #IMPLIED 

max-val CDATA #IMPLIED 

val-inc CDATA #IMPLIED> 
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<!-- Definition for a policy block instance defined within the composite 

policy block class, 'class* is the ID of the class used for the instance. 

— > 

<! ELEMENT policy-block-def ((policy-block-parm-def | policy-block-input-def | 

policy-block-input-set-def | policy-block-input-set-bus-def)*)> 
<! ATTLIST policy-block-def 

id CDATA #REQUIRED 

class CDATA #REQUIRED> 

<!- Policy block parameter definition - contains value of parameter 

Value' can include ${parm-id} for substitutions from value of corresponding 
composite block parameters — > 

<!ELEMENT policy-block-parm-def EMPTY> 

<!ATTLIST policy-block-parm-def 
id CDATA #REQUIRED 

type (i32-val | i64-val | double-val | bool-val | string-val) #REQUIRED 
value CDATA #REQUIRED> 

<!— Block input definition - defines signal reference for input --> 
<! ELEMENT policy-block-input-def (abs-signal-ref | rel-signal-ref | 
variable-signal-ref | input-signal-ref | input-set-signal-ref)> 
<! ATTLIST policy-block-input-def 
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id CDATA #REQUIRED> 

<!-- Block input set definition - defines signal references for input set --> 
<!ELEMENT policy-block-input-set-def ((abs-signal-ref | rel-signal-ref | 

variable-signal-ref | input-signal-ref | input-set-signal-ref)*)> 
<!ATTLIST policy-block-input-set-def 

id CDATA #REQUIRED> 

<!- Block input set bus definition - defines link to input set for 

composite policy block class to link to input set of block. -> 

<!ELEMENTpolicy-block-input-set-bus-defEMPTY> 

<!ATTLIST policy-block-input-set-bus-def 
id CDATA #REQUIRED 
input-set-id CDATA #REQUIRED> 

Appendix D: Sample XML-encoded Policy Class Definition 

<?xml version="l . 0" ?> 

<!DOCTYPE policy-composite-class SYSTEM "nbPolicy . dtd" > 

<!-- 

Class name for MinMaxTimeThresh class 

This class implements an extension of the basic min-max 
threshold, adding in a parameter for determining the 
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minimum time that a threshold needs to exceed the bounds. 



++MinMaxTimeThresh+++++++++++++++++++++++++++++++++++ 



++minmaxthr++++ ++mintimel++++++ 



toohigh++++input output+++++toohigh++ 



++input+++input 



+ + min time= 



+ + 1 $ {min_time} ' + | 



toolow++ 



+ min= ' $ {min} ■ + 



+ max= • ${max} 1 + 



++norblock++++++ 



+++=inputs output ++normal++ 



++/+ 



++++++++++++++++ 



+++++++++++++++++ 



++mintime2++++++ | 



+++input output ++++++toolow++ 



+ min time= 



+ ' ${min_time} ' + 



++++++++++++++++ 



+++++++H 
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- - > 

<policy-composite-class class="MinMaxTimeThresh" 
label= "Min/Max threshold with min time"> 
<!-- Define an input for the value --> 
<policy-input-def id="input" type=" double -val" 

label=" Input "/> 
<!-- Define a 'too high' output --> 
<pol i cy- output - de f id= " toohigh " type = 11 bool - val " 

label=" Value too high"> 

<rel-signal-ref block- id="mintimel" output-id= "output "/> 
</policy-output-def > 
<!-- Define a 'too low' output --> 
<policy-output -def id= " toolow" type= "bool -val " 

label= "Value too low"> 

<rel- signal -ref block- id= "mint ime2 " output -id= "output "/> 
</policy-output-def > 
<!-- Define a 'normal' output --> 
<policy-output-def id= "normal " type= "bool -val " 

label= "Value in range "> 

<rel-signal-ref block- id="norblock" output -id="boutput "/> 
</policy-output-def > 
<!-- Define the 'min' parameter --> 
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<policy-parm-def id="min" label= "Minimum Value" advanced="no"> 

<double-parm-def def ault="0 . 0"/> 
</policy-parm-def > 

<!-- Define the 'max' parameter --> 

<policy-parm-def id="max" label= "Maximum Value" advanced="no"> 

<double-parm-def def ault="100 . 0"/> 
</policy-parm-def > 

<!-- Define the 'min_time» parameter --> 

<policy-parm-def id="min_time" label= "Minimum time for error" 
advanced= " no " > 

<double-parm-def def ault="10 . 0"/> 

</policy-parm-def > 

<!-- Create an embedded block based on the MinMaxThreshFloat 
class --> 

<policy-block-def id="minmaxthr" class= "MinMaxThreshFloat " > 
<!-- Tie the input to the block input --> 
<policy-block- input -def id= " input " > 

< input - s ignal - re f input - id= " input " / > 
</policy-block- input -def > 

<!-- Tie the min parm to the block min parm --> 
<policy-block-parm-def id="min" type="double-val" 

value= " $ { min } " / > 
<!-- Tie the max parm to the block max parm --> 
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<policy-block-parm-def id= "max" type= "double -val " 
value="${max} "/> 
</policy-block-def > 

<!-- Create first mintime block for toohigh --> 
<policy-block-def id="mintimel" class="MinTimeBool"> 

<!-- Input from toohigh signal 

<policy-block- input -def id=" input "> 

<rel-signal-ref block- id= "minmaxthr" output - 

id= " toohigh "/> 

</policy-block- input -def > 

<!-- Get min_time parm from block --> 

<policy-block-parm-def id="min_time" type = "double -val " 
value="${min_time} "/> 
</policy-block-def > 

<!-- Create second mintime block for toolow --> 
<policy-block-def id="mintime2 " class="MinTimeBool" > 

<!-- Input from toolow signal --> 

<policy-block- input-def id= " input " > 

<rel- signal -ref block- id= "minmaxthr" output - 

id=" toolow" /> 

< /policy-block- input -def > 

<!-- Get min_time parm from block --> 

<policy-block-parm-def id="min_time" type="double-val " 
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value="${min_time} "/> 
</policy-block-def > 

<!-- Create the NOR block for the normal output --> 
<policy-block-def id= "norblock" class= "NORBool " > 
<policy-block- input -set -def id="blkinputs"> 

<!-- Get one input from 'output 1 on •mintimel' --> 
<rel-signal-ref block-id="mintimel" output - 

id=" output "/> 

<!-- Get one input from 'output' on 'mintime2' --> 
<rel- signal -ref block- id= "mintime2 " output - 

id= " output "/> 

</policy-block- input -set -def > 

</policy-block-def > 

< /policy- compos ite-c las s> 

Appendix E: Sample Alert Profile in XML 

<variable varid="nbAlertProf ile_def ault " class="nbAlertProf ile" 
persistent= "yes " nodelete= "yes " > 

<struct-val> 

<struct -element f ieldid="disableuntil"> 

<utc-val>0</utc-val> 

</ struct -element > 

<!-- Schedule 0 - first alert level (start 0, repeat 300, end 

600) --> 

<struct-element f ieldid="sched_0"> 
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<struct-val> 
<struct-element f ieldid= "label " > 
<!-- get text ("First Alert Level") --> 

<nls-string-val raw="%{ | First Alert Level%}"/> 
< / s t rue t - e 1 emen t > 
< struct -element f ieldid="Tstart "> 
<u32-val>0</u32-val> 
</ struct -element > 

<struct-element f ieldid="Nrepeats" > 
<u32-val>2</u32-val> 
</ struct -element > 

<struct -element f ieldid="Tperiod"> 

<u32-val>3 00</u32-val> 
</struct-element> 

<struct -element f ieldid="enab_sched" > 

<string-val>0 0 0 0 0 0 0</string-val> 
</ struct -element > 

<struct -element f ieldid=" act list "> 
<varid-list-val> 
<varid-val>nbAlertAct_nbSendEmail_primary</varid-val> 
<varid-val>nbAlertAct_nbSendSMSEmail</varid-val> 
<varid-val>nbAlertAct_nbSendHTTP_def ault</varid-val> 



1017-0038-US Application.FINAL 



-46- 



Attorney Docket No.: 1017-0038-US 

<varid-val>nbAlertAct_nbSendFTP_def ault</varid-val> 
</varid-list-val> 
</ struct -element > 

<s true t -element f ieldid="isdef ault "> 

<bool-val val="true"/> 

</ struct -element > 

</struct-val> 

</struct- el ement > 

<!-- Schedule 1 - second alert level (start 1200 # repeat 600, 
end 600) --> 

<struct-element f ieldid="sched_l" > 

<struct-val> 

<struct-element fieldid= "label " > 

<!-- get text ("Second Alert Level") --> 

<nls-string-val raw="%{ | Second Alert Level%}"/> 

</struct-element> 

<struct -element f ieldid="Tstart"> 

<u32-val>1200</u32-val> 

</ struct -element > 

<struct-element f ieldid= "Nrepeats " > 

<u32-val>l</u32-val> 
</ struct-element> 

<struct-element f ieldid="Tperiod" > 
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<u32-val>600</u32-val> 
</ struct -element > 

<struct-element f ieldid="enab_sched" > 

<string-val>0 0 0 0 0 0 0</string-val> 
</struct -element > 

<struct -element f ieldid="actlist " > 
<varid-list-val> 
<varid-val>nbAlertAct_nbSendEmail_secondary</varid-val> 
<varid-val>nbAlertAct_nbSendSMSEmail</varid-val> 
<varid-val>nbAlertAct_nbSendHTTP_def ault</varid-val> 
<varid-val>nbAlertAct_nbSendFTP_default</varid-val> 
</varid-list-val> 
< /struct -element > 

<struct -element f ieldid= " isdef aul t " > 

<bool-val val="true H /> 

</ struct -element > 

</struct-val> 

</ struct -element > 

<!-- Schedule 2 - third alert level (start 5400, repeat 3600, end 
10800) --> 

<struct-element f ieldid= " sched_2 " > 

< struct -val> 

<struct -element fieldid= "label "> 
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<!-- gettext ("Third Alert Level") --> 
<nls-string-val raw="%{ | Third Alert Level%}"/> 

</ struct -element > 

<struct -element f ieldid="Tstart "> 
<u32-val>5400</u32-val> 

</ struct -element > 

< struct -element f ieldid="Nrepeats"> 

<u32-val>2</u32 -val> 
< /struct -element > 

<struct-element f ieldid= "Tperiod" > 

<u32-val>3600</u32-val> 
</ struct-element> 

< s t ruct - element f ieldid= " enab_sched " > 

<string-val>0 0 0 0 0 0 0</string-val> 
</ struct -element > 

<struct- element f ieldid=" act list "> 
<varid-list-val> 
<varid-val>nbAlertAct_nbSendEmail_primary</varid-val> 
<varid-val>nbAlertAct_nbSendEmail_secondary</varid-val> 
<varid-val>nbAlertAct_nbSendSMSEmail</varid-val> 
<varid-val>nbAlertAct__nbSendHTTP_default</varid-val> 
<varid-val>nbAlertAct_nbSendFTP_def ault</varid-val> 
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</varid-list-val> 
</s true t -element > 

< struct -element f ieldid="isdef ault '"> 

<bool-val val="true"/> 

</ struct-element> 

</struct-val> 

</ struct -element > 

<!-- Schedule 3 - base periodic level (start 0, repeat 60, end 
4000000000) --> 

<struct-element f ieldid="sched_3 "> 

<struct-val> 

<struct-element f ieldid="label" > 

<!-- gettext ("Continuous Alert") --> 

<nls-string-val raw= "%{ | Continuous Alert%}"/> 

</s true t -element > 

<struct-element f ieldid="Tstart"> 

<u32-val>0</u32-val> 

</struct-element> 

<struct-element f ieldid="Nrepeats"> 
<u32-val>1000000</u32-val> 
</ struct-element > 

<struct- element f ieldid="Tperiod"> 
<u32-val>60</u32-val> 
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</ struct -element > 

<struct -element f ieldid="enab_sched"> 

<string-val>0 0 0 0 0 0 0</string-val> 
< /struct -element > 

<struct -element fieldid= "act list "> 
<varid-list-val> 
<varid-val>nbAlertAct_nbSendSNMPTrap</varid-val> 
<varid-val>nbAlertAct_nbPlayAudioAlert</varid-val> 
</varid-list-val> 
</struct -element > 

<s t rue t -element f ieldid="isdef ault "> 

<bool-val val="f alse"/> 
</ struct -element > 
</ struct-val> 
</ struct-element> 
</struct-val> 
<metadata slotid="nbLabel"> 

<nls-string-val raw="%{ | Def ault% } "/> 
</metadata> 
</variable> 
Appendix F: Sample Alert Action Handler Registration 

<!-- Send e-mail action class --> 
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<variable varid= M nbAlertActCls_nbSendEmail M 
class= n nbAlertActionClass"> 

<struct-val> 

<!-- E-mail notification list --> 

<struct- element f ieldid="parm_0"> 

< struct -val> 

<struct-element f ieldid="id" > 

<string-val>notify</string-val> 

</ struct-element> 

<struct -element f ieldid="type"> 

<string-val>string</string-val> 

</ struct -element > 

<s truct -element f ieldid= " subtype " > 

<string-val>notifylist</string-val> 
< / s t rue t - e 1 emen t > 

<struct-element f ieldid=" advanced" > 

<bool-val val="f alse"/> 
</st rue t -element > 

<struct-element f ieldid="def ault " > 

<string-valx/string-val> 
< /struct - element > 
< struct -element f ieldid= " label " > 



1 0 1 7-0038-US Application.FINAL 



-52- 



Attorney Docket No.: 1017-0038-US 
<!-- gettext ("E-mail Addresses") -- 

> 

<nls-string-val raw="%{ | E-mail 

Addresses" /> 

</ struct -element > 
</struct-val> 
</ struct- element > 
<struct-element f ieldid= "parm_l " > 
<struct-val> 

<struct-element f ieldid="id"> 

< string-val>incerrornot if y</ string - 

val> 

</ struct -element > 

<struct -element f ieldid="type"> 

<string-val>bool</string-val> 
</ struct -element > 

<struct-element fieldid= "advanced " > 

<bool-val val=" false "/> 
</struct- element > 

<struct-element f ieldid="def ault " > 

<bool-val val="true"/> 
</ struct -element > 
<struct- element fieldid= "label "> 
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<!-- gettext ( "Include Threshold- 
specific Addresses") --> 

<nls-string-val raw="%{ | Include 

Threshold-specific Addresses"/> 

< /struct -element > 
</struct-val> 
</ struct -element > 
<struct -element f ieldid="exec"> 
<string- 

val>/opt/netbotz/bin/nbSendEmailAlert</string-val> 
< /struct - element > 

<struct-el ement fieldid=" max_runs " > 

<u32-val>l</u32-val> 
</struct-element> 

<struct -element f ieldid="canincpix" > 

<bool-val val="true"/> 
</struct -element > 

<struct-element f ieldid="canincsnd" > 

<bool-val val="true"/> 
</ struct -element > 

<struct -element f ieldid="canincgraph" > 

<bool-val val="true"/> 
</ struct- element > 
</struct-val> 
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<metadata slotid="nbLabel " > 

<!-- gettext ("Send E-mail") --> 

<nls-string-val raw="%{|Send E-mail%}"/> 

</metadata> 

</variable> 

Appendix G: Sample Alert Action Instance 

<!-- Default e-mail action "primary notification e-mail" --> 

<variable varid="nbAlertAct_nbSendEmail ^primary" 
class= "nbAlertAction" persistent= "yes " > 

<struct-val> 

< struct -element fieldid= "class "> 

<varid-val>nbAlertActCls_nbSendEmail</varid- 

val> 

</struct-element> 

<struct-element f ieldid= "parm_0 11 > 
<struct-val> 

<struct -element f ieldid= " id" > 

<string-val>notify</string-val> 
</ struct -element > 

<struct -element f ieldid=" setting" > 

<string-valx/string-val> 
</ struct-element> 
</struct-val> 
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</ struct -element > 
<struct-element f ieldid="parm_l M > 
<struct-val> 

<struct -element f ieldid= " id" > 

<string-val>incerrornotify</string- 

val> 

</ struct -element > 

<struct-element fieldid= "setting" > 

<bool-val val="true"/> 
</ struct-element> 
</struct-val> 
</ struct-element> 
< struct -element f ieldid="sched" > 

<string-val>0 0 0 0 0 0 0</string-val> 
< / s t rue t - el ement > 

<struct -element f ieldid="sevlist" > 

<string-list-val>< ! -- empty list = all 

severities--> 

</ string- list -val> 
</ struct -element > 

< struct- element f ieldid= "errtypes " > 
<varid-list-val> 
</varid-list-val> 
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</s t rue t -element > 

< struct -element f ieldid= n incpix"> 

<u32-val>10</u32-val> 
</ struct-element> 
<struct-element f ieldid="incsnd"> 

<bool-val val= ,? f alse"/> 
</ struct -element > 

<struct-element f ieldid= M incgraph" > 

<bool-val val= M true"/> 
</ struct-element> 
</struct-val> 

<metadata slotid="nbLabel M > 

<!-- ge t text ( "Primary E-mail Notification") --> 
<nls-string-val raw="% { | Primary E-mail 

Notification%} "/> 

</metadata> 
</variable> 
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